You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please check if your PR fulfills the following requirements:
Tests for the changes have been added (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
Bugfix
Feature
Code style update (formatting, local variables)
Refactoring (no functional changes, no api changes)
Build related changes
CI related changes
Documentation content changes
infrastructure changes
Other... Please describe:
What is the current behavior?
Changes to nested route escaping in RC0 broke what was essentially flat routing, where files/folders named along the lines of a.b.c would have their path become a/b/c. This is useful for reducing folder nested. Whether it was an intentional behaviour previously I'm not sure, but I'd like it to be there.
What is the new behavior?
Adds back the . -> / regex that was removed in RC0, bringing back flat route support.
Other information
Having flat routing alongside nested routing does add the potential for multiple definitions of the same route, but IMO the convenience outweighs that risk
One thing I wasn't sure about here was what this did for people who wanted . in the path. I added it to solve unnesting very briefly and almost immediately regretted it. That's why I went back against this because I could already picture the issues being opened when someone made route.json.ts and it wasn't at route.json. There are cases where people make extension specific routes at minimum. Especially for known things like... manifest.json etc. I know Remix does flat routing. Did they ever solve this?
Looks like Remix use [] to escape characters, whether that's individual periods with manifest[.]json.ts or entire file names like [manifest.json].ts. They use $ as their dynamic route prefix similar to how SS uses : so there's no conflict with dynamic files, but they also use $.ts on its own (which i quite like tbh) to do splat routes, whereas for us doing something like [...rest].tsx would conflict with our splat routes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Changes to nested route escaping in RC0 broke what was essentially flat routing, where files/folders named along the lines of
a.b.cwould have their path becomea/b/c. This is useful for reducing folder nested. Whether it was an intentional behaviour previously I'm not sure, but I'd like it to be there.What is the new behavior?
Adds back the
. -> /regex that was removed in RC0, bringing back flat route support.Other information
Having flat routing alongside nested routing does add the potential for multiple definitions of the same route, but IMO the convenience outweighs that risk